為什麼要寫這系列的文章？

稍有經驗的開發者，可能都對 SPA ( Single Page Application ) 不會太陌生，其原理都是藉由廣為人知的 JavaScript 來處理大部分的任務，進而做到前後端分離、增加使用者體驗等等，但事情總是兩面的，SPA 也有對應的缺點，那就是 SEO 較差且不支援 no-script 模式。

而為了解決 SEO 這項致命傷，SSR ( Server Side Render ) 這概念順應而生，網路上蠻多文章都在解釋什麼是 SSR，我就在這稍微提一下，讓各位讀者比較好理解。

平常我們在做 SPA 網站時，都會有一隻 HTML 檔，
裡面的樣式大概長如下

而當爬蟲來爬時，就只會看見一個 div，其他內容都必須等 JS 去執行撈資料、塞資料、Render 畫面等步驟執行完後才出現，所以想當然爾，SEO 當然就不會好到哪去，而在 SSR 中，第一次進來的畫面，就不只是 div 孤孤單單一個人在那了，而是依照網址的路徑來決定要渲染什麼畫面並顯示在前台上，且會把你藉由 Webpack 建立起的 Bundle.js 檔載入，由它來完成接下來使用者的操作和渲染。

所以總結一句，在 SPA 中 SSR 和 CSR 的不同就只有在第一次的畫面是由誰 Render 而已

而為了要做 SSR，要做的事情可多著呢，這邊就簡單舉幾個例子

1. 你藉由 componentDidMount 生命週期來取得資料嗎？
2. 你藉由 react-router 來配置路由嗎？
3. 你藉由 i18n 來處理多國語言嗎？
4. 你藉由 Redux 來集中管理資料嗎？
5. 你藉由 CSS-in-JS 來做樣式處理嗎？

以上五點有任何一點符合，你都需要再多寫幾段程式碼來配合 SSR

那要改善 SEO 就只有 SSR 一條路可以走嗎？

孩子，當然不是，條條大路通羅馬啊

除了 SSR 之外，我們還有 預渲染 ( Pre Rendering ) 這條路能走。

而這系列文的主角，Gatsby.js 便是預渲染的 Library

展望與目錄

去年參加鐵人賽時，由於沒有存稿的關係，每天查資料、寫稿、潤稿就花了不少時間，也在心中默默地發誓，如果今年要再參加，一定要存十篇以上的稿量，不然死都不參加，結果昨天最後一天報名，還是默默地按下去了。

既然都報名了，當然是努力撐到最後啊！

先前在處理 SPA 的 SEO 問題吃了不少羹，所以想藉由這三十天的努力將 Gatsby.js 盡可能地摸熟，讓自己對於這部分的業務，不會這麼的手足無措。

往後的三十天會以下面這幾點為主軸去撰寫文章

• 什麼是 Gatsby.js ？
• Gatsby 與 Next 的差異
• Gatsby Plugin
• Gatsby Template
• Gatsby 與 CMS 的串接
• GraphQL 簡介與應用
• Gatsby 部署

如果發現篇幅不夠支撐三十天的份量，可能就會再以類似的 Library 去做差異比較，如 react-snap、react-static，或者就進入到 Next 的主題，總之且戰且走吧！

這一系列誰適合看

會基本的 JavaScript，最好有碰過一些主流框架 ( React 、Angular、Vue )，且想知道如何加強 SEO

參考資料

Server Side Rendering pros and cons. When to use it and when to choose something else
前端三十｜18. [FE] 為什麼網站要做成 SPA？SSR 的優點是什麼？
React | 用實作了解 Server-Side Rendering 的運作原理